1. Field of the Invention
The present invention relates generally to supporting transactions in a distributed object-oriented computing environment, and more specifically to a system and method implemented in such an environment for allowing a thin client to start and coordinate a global transaction using a two-phase commit procedure.
2. Description of the Related Art
During the 1960's, when computers began to become a permanent and widespread feature of the business environment, the accepted model for computing was a large mainframe computer, such as the IBM 360, acting as a host or server providing computer services for a large number of dumb terminal clients. Following that trend into the 1970's, that model became the standard with the advent of operating systems such as the Virtual Machine (VM) operating system, running on computers such the IBM 370. Mainframe computers of that era typically shared characteristics including a large main memory space, an extensive repertoire of instructions, fast operations, and considerable cost. The mainframe's operating system allowed each user to access the mainframe from a terminal having limited hardware and software intelligence on a time-sharing basis. With the high cost/high capability of the host making for a relatively rich server, it only made sense to have low cost/low capability of relatively "thin" clients.
With the advent of the personal computer, and its virtual explosion of popularity following the introduction of the IBM Personal Computer (IBM PC) in 1981, the computing model began to change. Through the 1980's personal computers grew in popularity and the price of computing hardware, including memory, dropped dramatically. The model for computing shifted to accommodate powerful user-centralized systems, as individual users harnessed more and more raw computing power on their desktops. The need for centralized management and control of resources such as printers and certain software, still left a place for a host/ or server/client providing access to many clients. However, the clients were no longer dumb terminals, instead the clients were relatively powerful themselves, having large capacity main memory as well as storage memory, usually in the form of a well known hard disk. Thus the server/client model commonly became one involving, relatively speaking, "fat" clients.
The 1990's have witnessed a growing popularity of the Internet and the world wide web, a multimedia subset of the Internet. The Internet serves as a worldwide network linking computers all over the globe to each other. Many have predicted that the Internet will once again change the model of computing back to a server hosting a lot of dumb terminal clients. The rationale is that the accessibility of software over the Internet will make the need for a powerful desktop computer fade away. Instead software can be accessed on demand and the remote server or servers will perform the requested functions and provide access to the requested resources. Thus, the client computing model has once again turned to the need to support thin clients. Such modern thin clients have little need for very much electronic or main memory and practically no need for a hard disk.
The computing model for many servers over the Internet serving a plurality of thin clients is attractive because it reduces the cost of ownership for computer users and reduces the threat of their workstations becoming obsolete due to computer programs requiring more and more memory for execution. The memory demands may now be satisfied at the servers while the same thin clients may be used for years to come.
Unfortunately, new problems are created for thin clients when they are included in the worldwide environment of distributed transaction-oriented computers. In a general sense a transaction in a computing environment is an exchange between one computing entity and another that accomplishes a particular action or result. For example, the entry of a customer's deposit and the updating of the customer's balance is a single transaction from the customer's point of view but involves a group of changes by an application transaction program that handles the transaction. One or more application transaction programs must interface with database files, referred to as resources, that have their own management software (resource managers) to access data and make changes to it. A procedure having specific rules, known as a commitment control protocol, ensures that a group of changes made to different database files, such as the above-referenced deposit and balance files, are synchronized so that multiple files all reflect the transaction.
It's estimated that, by the year 2000, business worth 600 billion dollars will be transacted over the Internet alone. This trend toward ever-increasing electronic commerce means that more resources will be distributed over networks globally accessible over the Internet, and continue to be spread over local area and wide area networks. Typically, in distributed computing environments, the commitment control procedure requires that each piece of transaction management software synchronize with the other transaction management software involved in the encompassing transaction taking place over the network. This synchronization ensures that data is not changed in any databases until all are in agreement that the change will be considered permanent.
The synchronization ensures the integrity of business processes and data by enforcing an "all or nothing" methodology. Each transaction is processed in its entirety, or not at all. This is sometimes referred to as atomicity. If a failure occurs during processing, the synchronization protocol will recover to the state before the request arrived, allowing the transaction to be retried if appropriate. The specific mechanism enforcing this behavior is a software component known as the transaction manager. When an application accesses multiple resources such as files, databases, and message queues, the transaction manager coordinates the updates to these resources, ensuring that either all updates are performed together or none are performed. It uses a method known as the two-phase commit procedure to achieve this. The two-phase commit procedure includes a voting phase in which resource manager indicates that his resource is prepared to commit, and a commit phase indicating that the data has been changed or updated. If the voting phase indicates a problem the data is not committed and the transaction does not occur.
A transaction manager component exists for each system that manages a resource along with resource management software that is responsible for managing the resource. The transaction manager is the controlling entity of the two management software entities. But there is a trend toward computers that are essentially network workstations that operate software that is passed to them over a network such as the Internet or an entity's smaller internal version of the same, called an intranet. Such workstations do not have their own storage, such as hard disk drives, and therefore cannot store their own data. Therefore such workstation machines cannot include their own data in transactions, which is a limitation of the prior art workstations. Without their own datastore, they have no way to guarantee that their data will remain in synch with data being changed on other computers that have such a store and which participate in the transaction.
The above-described problem is more complex in a distributed "object-oriented" environment. Objects are becoming very popular with computer programmers because their use can greatly reduce software development time and expense. In object oriented programming, program code may be inherited from objects as long as there is an underlying system, sometimes referred to as a framework that supports the objects and allows the inheritance to take place. The object encapsulates or contains properties such as certain executable code and data that is consistently reusable whenever a procedure or method is performed on the object. To ensure that they retain their properties, objects need to be saved in non-volatile locations, such as disk storage, where they are managed by resource management software, such as a relational database manager or object database manager. This is referred to as persisting the object. Thus, an advantage of objects is that one representation of an object persisted in disk memory may be used in by various site's application programs.
A disadvantage for the programmer who is concerned with ensuring the integrity of distributed transactional data involving client applications from network workstations not having their own persistent store is the inability to synchronize data through the use of a two-phase commit protocol.
Prior art transaction managers relied on the client's persistent storage to track the state of resources involved in a transaction in the event of failure so that the resources could be recovered. Therefore, clients having no persistent storage were not allowed to start a transaction that used a two-phase commit procedure. It would be an advancement in the art to provide a mechanism for allowing a thin client to start a global transaction while ensuring that atomicity is maintained.